Tool Mentor: Recording a Performance Test Session

Purpose

This tool mentor describes how to record a performance test using Rational LoadTest and Rational Robot.

Related Rational Unified Process activities:

Section "Record, Generate, or Program Test Scripts" of Activity: Implement Test

Overview

You can use LoadTest to conduct performance tests, which help to determine whether a multi-client system is performing within its user-defined standards under varying workloads. Performance tests involve loading the server with many virtual users. For example, you might have a timer on one virtual user to find out how much time a query takes when 1000 other virtual users are sending requests to the same server at the same time.

Performance testing includes the following types of tests:

Load Tests ù designed to test client or server response times under varying workloads. Also used to help testers compute the maximum number of transactions a server can handle over a given period.

Stress Tests ù running your client application under extreme conditions to see if the application or the server "break." Examples include continuously running a client application for many hours; performing a large number of transactions; having hundreds of users perform the same operation at the same moment.

Contention Tests ù executing a combination of GUI and virtual users on one or more computers to simulate an actual user environment. This type of test identifies problems such as locking, deadlock conditions, and concurrency controls.

Configuration Tests ù test that your product will continue to run on multiple platforms. By running the same tests on different computers you can test for compatibility issues, determine the minimum and optimum configuration of hardware and software needed for running the application, and learn how each part of your application performs on each different configuration.

When you record virtual user scripts for any of the above tests, you are actually recording a session. The session contains all of the client requests and server responses issued from the time you begin recording until the time you stop. The sessions are recorded using Rational Robot. After recording, Robot generates one or more scripts from the session.

To record a performance test session:

Set recording options.
Record the session.
Split the session into multiple scripts.
Add features to the script.

Also see the following tool mentors for additional related information:

1. Set recording options.

Before you record a virtual user script, make sure the recording options are set the way you want them for the recording session. You can review and set virtual user recording options in any of these ways:

Before you begin recording, click Tools « Virtual User Record Options in Robot.
When you initiate recording, click Options in the Record Virtual User dialog box.
When you end recording, click Options in the Stop Recording dialog box. At this time, you can only set options that affect script generation. (In the first two cases, you can set any of the options on any of the tabs.)

For information on these options, click the Help button in the dialog box.

2. Record the session.

Robot gives you considerable recording flexibility for virtual user scripts for performance testing. You can record:

Multiple transactions. For example, you can record a data entry transaction and a query transaction in the same recording session, one after the other.
Transactions against the same server or different servers. For example, you can record one transaction against one Web server, and then record another transaction against a different Web server.
Different types of requests in the same session. For example, you can record Oracle, Microsoft SQL Server, HTTP, and TUXEDO requests in one session.

The procedure for recording a virtual user script is found in Chapter 4 of the Using Rational LoadTest manual, which can be found on the documentation CD.

3. Split the session into multiple scripts.

Typically, each script recorded during a session contains a logical set of actions performed by one user. For example, if you record a query transaction against a Web server and an order entry transaction against a database server, you would probably split the session into two different scripts ù one for each transaction.

Splitting a session into multiple scripts is also a convenient way to treat sections of the recording sessions differently when you emulate the workload. For example, suppose you log into a database sever and perform three different transactions. If you split the session so that the login and each transaction is a separate script, you can set up the workload schedule to perform many iterations of the transactions but perform the login script just once.

The procedure for splitting a session into multiple scripts is found in Chapter 4 of the Using Rational LoadTest manual, which can be found on the documentation CD.

4. Add features to the script.

The following features can be added to a virtual user script:

Comments
Blocks
Synchronization points
Timers

Comments
A comment is a line of text in a script that begins and ends with special characters so that they will not be executed as part of the script. Comments are ignored at script compile time and during script playback. Use comments to document the script and to help you find your way around the script if you later need to edit it. Comments can be added both during recording and during editing.

Blocks
A block is a set of contiguous lines of code that you want to make distinct from the rest of the script. Typically you can use a block to identify a transaction within a script. A script can have up to 50 blocks. They can be nested, but not overlapped.

You may want to use blocks for the following reasons:

To associate the block and timer names with the emulation command that performs the transaction.
To include the block name in the LoadTest reports, thus enabling you to filter the reports with the block name.
To make the script easier to read, and to provide an immediate context for a line within the block through command IDs.

Synchronization Points
A synchronization point lets you coordinate the activities of a number of users by pausing the execution of each user at a particular point ù the synchronization point ù until one of the following events occurs:

All users associated with the synchronization point arrive at the point.
A timeout period is reached before all users arrive at the point. You specify the timeout period.
You manually release the users while monitoring a schedule run in LoadTest.

When one of these events occurs, LoadTest releases the users, allowing them to continue performing the transaction.

Timers
Individual emulation commands are timed automatically. By default, they are included in the LoadTest report output. However, if you want to measure the time it takes a virtual user to perform an activity, you can insert a timer in the script. The timer works like a stopwatch. Timers are useful if you want to time an overlapping sequence of events. They can also be used when you want to time a very specific portion of the script.

The procedures for adding comments, blocks, synchronization points, and timers to a script, and information on using the Insert menu, are found in Chapter 5 of the Using Rational LoadTest manual, which can be found on the documentation CD.

Rational Unified Process